Subject: Timestamps in SNA Related MIBs

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 3 Nov 1995 16:32:00 -0500

At the APPN MIB session at the recent AIW there was some heated discussion
about time stamps.  I do not know where all of the relevant mailing lists for
these discussions are.  In particular I cannot find a mailing list for the
APPC MIB.

On the one side there were the multiprotocol vendors.  For them SNA, APPN, HPR,
DLSw, and APPC are just a few more protocols to add to already crowded boxes.
They want to treat these protocols as much like the other protocols as
possible.  More particularly they want all agents to report the time stamps
for events in the same way so that a sequence of events can be correlated.
For example if there is a failure on a V.35 port and a failure of an SNA
route which happens to pass through that port, then it is considered HIGHLY
important that those two events have time stamps which are directly
comparable.  Note that the SNA NAU MIB and SNA DLC MIBs use sysUpTime
exclusively.

On the other side there are implementors of SNA only boxes which want to use
SNMP only because it provides a convenient common way of consistently
describing all equivalent components.  Several of these have vehemently
insisted that it is IMPOSSIBLE for them to report sysUpTime.

The only real value of SNMP is in its ability to represent all of the
management information about a network within the MIB.  For any individual
component a proprietary management interface will always be superior because
there is no need to compromise on the representation of the structure of the
information.  SNMP is only of value, therefore, when you can correlate
information presented by one component with information presented by another.
Using independent clocks for different components makes this correlation
difficult or impossible, and therefore raises the question "Why are you doing
SNMP management at all?"  The fact that the set of MIBs for which this
special treatment is being demanded are all IBM initiated and SNA related
creates special political problems.

It is difficult for many of us to accept the objections to implementing
sysUpTime.  In particular implementation of sysUpTime is MANDATORY for all
systems according to RFC1213.  It is therefore difficult to understand how
these vendors could claim to be implementing SNMP when they do not provide
this object.  I can appreciate that there are situations in which it is very
difficult to provide sysUpTime.  For example Nortel has one platform that
only has a time of day clock and does not record in the module when it was
started.  It also does not have an IP stack, or a sockets interface, or any
of the other myriad features which are assumed in SNMP.  That did not stop
Nortel from presenting sysUpTime out of our SNMP agent.  Even if the local 
implementation of any of these SNA protocol stacks does not wish to
interrogate sysUpTime every time a state change occurs in their service, all
that is necessary is for the service specific management agent to save the
value of sysUpTime at the time that the service started, and to add that
value to all of its internal timestamps at the point where they are reported
up to the management system.

However these implementors are presumeably genuine in their belief that it
is IMPOSSIBLE for them to present the sysUpTime values for events.  So
we have a conflict.

Now the APPC MIB has been proposed in draft-ietf-snanau-appcmib-04.txt to use
a protocol stack specific timer appcUpTime.  The MIB proposes that the
management station retrieve sysUpTime and appcUpTime and calculate an offset
to correct all of the time stamps which it retrieves from the MIB.  With this
precedent it is now proposed to use the same design for the APPN MIB and the
DLSw MIB.  The claim was made that "the IETF did not object to a private time
stamp".  However the APPC MIB is only a draft.  However the full set of SNA
related MIBs ideally should be enshrined as extensions of the standard
MIB-II, and the conditions of approval as an IETF standard are much tighter.

So on the one side we have the multiprotocol vendors and the architectural
purists who insist that all events should be time stamped with sysUpTime, and
on the other hand we have IBM, standing bravely alone and depending upon the
AIW's tradition of consensus to protect its unique right to special
treatment.

I do not believe that IBM has proved its case for special treatment, and that
therefore the AIW should not approve any of these MIBs for presentation to
the IETF until this case is established.  However in the spirit of consensus
I have proposed a compromise.  This requires changing slightly the definition
of xxxxUpTime in each of these proposed MIBs, and adding an additional object
in each MIB after xxxxUpTime.  The changes look like:

-- *********************************************************************
-- Textual Convention
-- ---------------------------------------------------------------------
 xxxxTimeStamp ::= TEXTUAL-CONVENTION
      STATUS current
      DESCRIPTION
|         "The value of xxxxUpTime when an event occurred.  Normally all
|	  events in this MIB are time stamped using sysUpTime.  However
|         there are implementations in which the value of sysUpTime is
|         not available to the xxxx management agent.  In this case the
|         value of xxxxUpTime is relative to the time when the xxxx
|         component came up.  A Management Station can relate
|         these time stamps to sysUpTime by retrieving sysUpTime and
|         xxxxUpTime, and calculating the difference between them."
      SYNTAX  TimeTicks
...
 
 xxxxUpTime  OBJECT-TYPE
     SYNTAX     TimeTicks
     MAX-ACCESS read-only
     STATUS     current
     DESCRIPTION
|       "This is equal to the value of sysUpTime if sysUpTime
|        is available to the xxxx portion of the system.  If the
|        value of sysUpTime is not available then it is the
|        time (in hundredths of a second) since the xxxx portion
|        of the system was last re-initialized."
     ::= { xxxx n }

|xxxxStartTime  OBJECT-TYPE
|    SYNTAX     TimeTicks
|    MAX-ACCESS read-only
|    STATUS     current
|    DESCRIPTION
|       "The value of xxxxUpTime at which the xxxx portion of
|        of the system was last re-initialized.  If the
|        value of sysUpTime is not available to the xxxx
|        portion of the system, then this value is set
|        to zero."
|    ::= { xxxx n+1 }

If an implementation wishes to present sysUpTime for all events then it is
freed by this proposal to do so.  If the implementation cannot report
sysUpTime values then it simply sets xxxxStartTime to zero and reports the
protocol specific relative times.  The wording is chosen to make it clear
that reporting sysUpTime values is preferred and an alternate clock is to be
used only if sysUpTime is not available.

This is not a totally satisfactory solution because a management station
cannot tell, except by examining the value of xxxxStartTime, or comparing the
values of xxxxUpTime and sysUpTime, which of the two techniques the
implementor has chosen.  

There are some stack specific notes.  The description of dlswNodeUpTime in
the DLSw MIB implies an implementation in which the entire DLSw service
evaporates whenever dlswState goes to inactive.  A more typical design is for
at least the SNMP agent to continue to exist even if the service which it
reports on behalf of is not currently running.  Therefore the description of
dlswNodeUpTime is proposed to be amended to permit the alternative
implementation:

 dlswNodeUpTime  OBJECT-TYPE
     SYNTAX     TimeTicks
     MAX-ACCESS read-only
     STATUS     current
     DESCRIPTION
|       "If sysUpTime is available to the DLSw management
|        agent then this is equal to the value of sysUpTime.
|	 However if the agent does not have access to sysUpTime
|	 then this is the time (in hundredths of a second)
	 since the DLSw portion of the system was last
|	 re-initialized.  That is, if dlswNodeStatus is active,
|        the time the dlswNodeStatus entered the active state.
|        It may be set to, and remain, zero if dlswNodeStatus is
|        inactive."
     ::= { dlswNode 6 }

Note that the name of the state object is incorrect in the text in draft 7 of
the DLSw MIB.

---

From: Wayne Clark <[email-masked]>
Date: Sat, 04 Nov 95 00:52:06 EST

>these discussions are.  In particular I cannot find a mailing list for the
[...]

Jim -

    The APPC MIB discussion happens on [email-masked].  Since I 
    maintain that list, I have gone ahead and added you to it.

    The mail log for that IETF working group can be found on ftp.cisco.com
    at:
	snanaumib/mail-archive

Regards,
Wayne